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ABSTRACT 



The present invention provides an interpreter with reduced 
memory access and improved jtmap-through-register han- 
dling. In one embodiment, a method includes storing a 
handler for a bytecode in a cell of a predetermined size of a 
table, and generating an address of the handler for the 
bytecode using a shift and an ADD operation. In particular, 
the handler address is generated by adding a base address of 
the table and an offset into the table. In another embodiment, 
a method includes prefetching a target handler address for 
providing improved jump-through-register handling. 

15 Claims, 10 Drawing Sheets 



// We use the fotowig variaEiles (stored In regfcters) In mese code 
n snippets: 

// 

/; rJPCPbsl stores (on entry to a bytecode handler) the value of the 
// byte thai sequenfiaVy follows the bytecode t)etng handled shllted 
U left by SHIFT.AMOUNT bits. The shift is don© to enable ho add.32 
// ttiat is at the entry of each handler to direct compute the address 
// ol the next bytecode handler. 
// 

// rJPCPbs 2 stores (on entry to a bytecode hamflex} the value of the 
// byre thai is the second byte that sequentially toDows the bytecode 
// being handled shlted loft by SHIFT.AMOUNT Ms. The shift is done 
// to enable the add.32 that Is at me entry ol each handler to direaty 
/; compute the address of (he next bytehcode handler. 

// rJPC is the address (on entry to a bytecode hartdler) of the byte thai 
// is the secoTKl trytg that seguertlally roOows the bytecode being handled. 

// Here^ a graphic fepresentaiion of rJPC. rJPCPhJSl. rJPCPIus 2 



//addre» 
//(in bytes) 
// 100 
// 101 
li 102 
0 103 



value 

10 
20 
30 
*0 



// If weYe processing the byte at address 100: 
//rJPC=102 

// rJPCPbjl = (20 « SHin AMOUNT) (the 20 comae from address 101 1 
// rjPCPIu$2 (30 « SH1F7_AM0UWT) (the 30 comes from address loej 

// SHlFT_AMOUf^ is a constam that Is detenrtned by the number of bytes 
// alocatsd for each opcode handler. For tnsitance, if 64 t^ss are allocated 
// for eacti opcode handier in e^ stale (O^ached, 1 -cacneo. &A. (hen 
// SHIFT. AMOUMT is 6 (2^ — 64) 

// rTOS is tie address of the tc^ ol the i^ttrand stack in memory. 
// rCach^ is cie register coritainlng (he on elemerit of me op«^ stack cache 
// iCachel is the register containing the Ist etement of the operand stack cache 
// rCaohe2 is the register containing the 2nd elemert of the operartd staA cache 

//r6 13 the special retfster that, when wrtttan to, preps (he branch predictor 
//to prepare to branch to Ois acbfisse. 



// rSwttchBase 0 is the address of (he table of opcode handlers with the state 

// *0 items in stadi cache' 

// 

// rSwtchBasel b (he atfcfnus of the table of opcode handlers w3h the state 
// *1 items in stack cache' 

// 

// rSwitchBase2 is the address of the tabb of opcode handlers wSh (he state 
// *2 items in stack cache' 



add.32 r6,rJPCF1us1, rSwrtchBssel //This is a t -byte opcode, so the next 

/r bytecode follow imnndtately 
or.32 TJPCPIiis1,rJPOPlus2.iO MowrJPCPlus2to iJPCPIusI 
Ida. 8 tJPCRus2. (+rJPC) U auto-hcremenl load from (rJPC) 

kl&.32 rTUP3,(rT0S-} /IT bad the two values and add them, 
lda.32 rTMP4,ifT0M // placing the resuh in (he slacit 
add,32 fCacheO, rTVP3, rTMP4 cache in register rCache 0 

sN 32 rJPCRus2. rJPCPtsa SHin_AM0UffT // Shift the vahia in 

// tJPCP1us2 as required 
ir r6 //jump to next bytecode handlBf 

iaod.lcachad: 

add32 rS. rJPCf^l . rSwltcffiasel // TMs ts a t-t^e opcode, so the next 

U bytecode follow imnnedifitely 
orJZ rJPCPIusl.rJPCPkjs2.tO Move rJPCPtusZ to rJPCPlMl 
lda.8 rJPCPtus2, (irJPC) tl auto4norement load from (rJPC) 

lda.32 rTVP3, (rTOS-) ^ bad the one value not kittestadt 

add32 iCatheO. rTMP3. rCacheO i7c8Cheandaddftti>tievanietn 
tfiCecheO.wnlingitbackto rC&cheO 

shl.32 rJPCPtus2. rJPCPIusS, SHlFT.AMaum' // SNfl (he vskie in 

^ iJPCP)u$2 as reQtireo 
jr r6 ^^mp to next byteoode handler 



add^ i8. rJPCRusi , rSwitcftBasel i7Thlt s a 1-byt» opcode, so the next 

U birtecode f oDow biiiiiedtat^ 
or.32 rJPCPhjsl.rJPCPkisS, lO ffMovarJPCPhjsJtorJPCPlusI 



lda.e rJPCPkrs2. (+OPC) // aus)-lncren»ra toad from (rJPq 

a(ld.32 rCacfteO,rCacheO.<Cachet //Add bom vafuasfwhicfi are stored 
// in he stack oeche St fCecheO end 
// (Cacnai), write resul to (Cacheo 

ShL32 rJPCPktf2,iJPCPtus2.SHlFTjWiOlWTflSrtacWvakJ9H 

iVrJPCnuSssrequred 
ir rfi ffjirrp 10 ten bytecode handler 
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// 

// Takes as input an array of strings that contains the program being compiled. 
// Uses the append() method to append bytes to the -bytecode-. 
// (bytecode is a Vector holding bytes). 

// 

public static void compile(String linesQ) { 
for (1 = 0; i < lines.length. i++) { 

String command = firstWord(lines[i]); // parse string and 

// get command name. 
String argument = otherWords(linesIi]); // get command parameters. 

if (command.equalsC'puts")) { 
// output bytecode for the PUTS command 
bytecode.append(OPC_PUTS); 

// now output the length of the string that follows puts 

// (in this Interpreter, we don't have variables or expressions 

// yet • so this is very basic!) 

bytecode.append(argument.length); // (string length must be < 256) 
// now output the bytes in the string... 
for (c = 0; c < argumentlength; C++) { // bytes in string 
bytecode.append(argument[c]); 



many more cases go in here 

else if (command.equalsC'exit")) { 
// output bytecode that tells the interpreter to return 
bytecode.append(OPC_EXIT); 



FIG. 3 
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public static void execute(bytecode[ ]) { 
int pc = 0; // my 'program counter' 
while (true) { 

int opcode = bytecode|pc]; // get an instruction (or 'opcode') 

// from bytecode 
switch (opcode) { // and switch on its type 

case OPC_PUTS: // Virtual Machine instruction to print a string 

// next byte is a length 
int len = bytecode[pc + 1]; 

// print out -len- bytes from the bytecode 
for (i = 1 ; i <= len; i++) ( printChar (bytecode[pc + i]); } 
// force pc to advance to the next instruction in bytecode 
pc = pc + len + 1 ; 
break; // done 

// many more cases ... 

case OPC.EXIT: // return from program 
return; 

} 




FIG. 4 
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void interpret (unsigned char *bytecodes) 

StackFrame frame; /* the stack frame for the method V 

/* setup the registers...*/ 

unsigned char *pc = bytecodes; 

Item *optop = frame.operand_stack; 

Item *vars = frame.locaLvarlables; 

while (1) { 

unsigned char opcode = *pc; I* get current instruction V 

switch (opcode) {/* switch on current instruction */ 

case OPCODE_dup: /* duplicate item on stack */ 
optop[0] = optop[-1]; 

/* update registers */ 
pc+= 1; optop-= 1; 
continue; 

case OPCODE_pop: /* remove Item from stack */ 
pc+= 1; optop -= 1; 
continue; 

case OPCODE_iadd: /* add two items on the stack V 



case OPCODE_return: /* return from method */ 
return; 

} 

} 

} 



FIG. 5 
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FIG. 7 



table_offset : = code « 6; // 64 = 2 ^ 
handler_address := table.base + table_offset; 



//Bytecode stream: 03 3b 84 00 01 1a 05 68 3b a7 ff f9 
// Disassembly: 

// Method void doMathForever( ) 

// Left column: offset of instruction from start of method 

// 1 Center column: instaiction mnemonic and any operands 

II ^ I Right column: comment 

0 iconst.O // 03 

1 istore_0 // 3b 
cir* o 2 line 0,1 // 84 00 01 
rlva. o 5 lload_0 // la 

6 iconst_2 // 05 

7 imul // 68 

8 lstore_0 // 3b 

9 goto2 // a7 ff f9 



byteO bytes 1-2 byte 3 byte 4 byte 5 bytes 6-7 
opO I opi argi i op2 ' op3 i op4 " op5 

FIG. 9 



Orlg State New State 
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1 r 

2 1 

3 2 
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opO handler: 

next_handler_addr := select handler addrfor byte 1 

// we dont need to update prefetch_1 since that just holds opi 

.prefetch_1 := prefetch of byte 2 

calculate handler addr for byte 2 

calculate handler addr for byte 3 

... do work for opO . . . 

jr next_handler_addr // this takes us to op1 handler 
op1 handler: 

next_handler_addr := select handler addr for byte 3 
prefetch_1 := prefetch of byte 4 
calculate handler addr for byte 4 
calculate handler addr for byte 5 
... do work for op1 . . . 

jr next_handler_addr // this takes us to op2 handler 
op2 handler: 

next_handler_addr := select handler addr for byte 4 
prefetch_2 := prefetch of byte 5 
calculate handler addr for byte 5 
calculate handler addr for byte 6 
... do work for op2 . . . 

jr next_handler_addr // this takes us to op3 handler 



FIG. 1 1 
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// We use the following variables (stored in registers) in these code 
// snippets: 

// 

// rJPCPIusI stores (on entry to a byteccde handler) the value of the 
// byte that sequentially follows the bytecode being handled shifted 
// left by SHIFT.AMOUNT bits. The shift is done to enable the add.32 
// that is at the entry of each handler to directly compute the address 
// of the next bytecode handler. 
// 

// rJPCPIus 2 stores (on entry to a bytecode handler) the value of the 
// byte that is the second byte that sequentially follows the bytecode 
// being handled shifted left by SHIFT_AMOUNT bits. The shift is done 
// to enable the add.32 that Is at the entry of each handler to directly 
// compute the address of the next bytecode handler. 
// 

// rJPC is the address (on entry to a bytecode handler) of the byte that 
// is the second byte that sequentially follows the bytecode being handled. 

// Here's a graphic representation of rJPC, rJPCPIusI , rJPCPIus 2 

// address value 
// (in bytes) 
// 100 10 
// 101 20 
// 102 30 
// 103 40 
// 

// If we're processing the byte at address 100: 
//rJPC = 102 

// rJPCPIusI = (20 « SHIFT.AMOUNT) 
// rJPCPIus2 = (30 « SHIFT.AMOUNT) 



the 20 comes from address 101 
Ihe 30 comes from address 102 



// SHIFT_AMOUNT is a constant that is determined by the number of bytes 
// allocated for each opcode handler. For instance, if 64 bytes are allocated 
// for each opcode handler in each state (0-cached, 1 -cached, etc), then 
// SHIFT_AMOUNT is 6 (2^^ == 64) 

// 

// rTOS is the address of the top of the operand stack in memory. 
// rCacheO is the register containing the 0th element of the operand stack cache 
// rCachel is the register containing the 1st element of the operand stack cache 
// rCache2 is the register containing the 2nd element of the operand stack cache 

// rS is the special register that, when written to. preps the branch predictor 
// to prepare to branch to this address. 



FIG. 14A 
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// 

// rSwitchBase 0 is the address of the table of opcode handlers with the state 
// °0 items in stack cache" 

// 

// rSwitchBasel is the address of the table of opcode handlers with the state 
//'I items in stack cache" 

// 

// rSwitchBase2 is the address of the table of opcode handlers with the state 
// '2 items in stack cache" 



iadd_Ocached: 

add.32 r6, rJPCPIusI , rSwitchBasel // This is a 1-byte opcode, so the next 

// bytecode follow immediately 
or.32 rJPCPIusI , rJPCPIus2, rO // Move rJPCPIus2 to rJPCPIusI 
lda.8 rJPCPIus2, (+rJPC) // auto-increment load from (rJPC) 

lda.32 rTMP3, (rTOS-) // load the two values and add them. 

Ida.32 rTMP4, (rTOS-) // placing the result in the stack 

add.32 rCacheO, rTMP3, rTMP4 // cache in register rCache 0 

shl.32 rJPCPIus2, rJPCPIus2, SHIFT_AMOUNT // Shift the value in 

// rJPCPIus2 as required 
jr r6 // jump to next bytecode handler 

iaddj cached: 

add.32 r6, rJPCPIusI , rSwitchBasel // This is a 1 -byte opcode, so the next 

// bytecode follow immediately 
or.32 rJPCPIusI , rJPCPIus2, rO // Move rJPCPIus2 to rJPCPIusI 
lda.8 rJPCPIus2, (+rJPC) // auto-increment load from (rJPC) 

lda.32 rTMP3, (rTOS-) // load the one value not in the stack 
add.32 rCacheO, rTMP3, rCacheO // cache and add it to the value in 

// rCacheO, writing it back to rCacheO 

shl.32 rJPCPIus2, rJPCPIus2, SHIFT_AMOUNT // Shift the value in 

// rJPCPIus2 as required 
jr r6 // jump to next bytecode handler 

iadd_2cached: 

add.32 r6, rJPCPIusI , rSwitchBasel // This is a 1-byte opcode, so the next 

// bytecode follow immediately 
or.32 rJPCPIus! , rJPCPIus2, rO // Move rJPCPIus2 to rJPCPIusI 



FIG.14B 
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lda.8 rJPCPIus2, (+rJPC) // auto-increment load from (rJPC) 

add.32 rCacheO, rCacheO, rCachel // Add both values (which are stored 

// in the stack cache at rCacheO and 
// rCachel), write result to rCacheO 

shl.32 rJPCPIus2, rJPCPIus2, SHIFT.AMOUNT // Shift the value in 

// rJPCPIus2 as required 
jr r6 // jump to next bytecode handler 



FIG. 14C 



table_offset : = code«6; //64 = 2* 

handler.address := table_offset; II since new state is 1 



FIG. 15 



03/02/2004, EAST Version: 1.4.1 



us 6,256,784 Bl 

1 2 

INTERPRETER WITH REDUCED MEMORY address of a first handler by adding a table base address and 

ACCESS AND IMPROVED a first table offset thereby eliminating the need for a memory 

JUMP-THROUGH-REGISTER HANDLING access to generate the address of the bylecode handler. In 

particular, the table base address is the starting address of the 
HELD OF THE INVENTION 5 table. The first table offset is the of&et into the table for the 

„ . . , . . first handler. 

The present invention relates generally to interpreters and, ^ . 

,-11, . . « %u J, J In one embodiment, the method mcludes stonng bytecode 

more particularly, to an interpreter with reduced memory . „ „ . t 

J. J. ... -^.ji- handlers m power of two size cells, such as 64 bvle cells, 

access and improved jump-through-register handlmg. "onux^t^* ah y i xv u vi.u^, uyv^ x^^ii^,. 

^ * Also, gcneratmg the address of a particular bytecode handler 

BACKGROUND OF THE INVENTION ^ efficiently implemented as a shift operation and an add 

operation. Accordingly, on modem microprocessors on 

Computer programs are typically written in source code which memory accesses are costly from a performance 

that must be translated into a native machine code so that the standpoint, this embodiment provides improved interpreter 

translated native machine code can be executed by a com- performance by reducing memory access during interpreta- 
puter. For example, Java™ technology uses both compila- 15 tion. 

tion and interpretation. Compilation is a process of trans- one embodiment, a method includes executing a first 

lating computer code from one language to another handler, and speculatively computing a first target and a 

language, and storing the results of that translation for later second target for a second handler whUe executing the first 

execution on a computer. Many well-known programming handler. In particular, this allows for providing a hint to a 
languages such as C, Pascal, and Fortran are usually com- 20 branch unit of a microprocessor to indicate the location for 

pHed straight from source code to native machine code (i.e., the next branch address before executing the next branch. In 

native instructions of a microprocessor). In contrast, the one embodiment, the hint is provided to the branch unit 

Java™ programming language is typicaUy compiled into ^isi^g a register to store the speculatively computed target 

Java™ class files, which contain architecture-independent address 

instructions for the weU-known Java™ Virtual Machine 25 embodiment, the method specuUtively computes 

(e.g Sun Microsystems Inc., provides a commetm^ first target and the second target in cider to provide a hint 

avadable package caUed the Java™ Development Kit (JDK) ^ ^ ^^^^^ ^^^j ^ destination of an approaching 

• ■ ^ • )• jump-through-rcgister for a Java™ interpreter. In particular, 

An interpreter is a program which performs the actions as the speculative computation is based on an empirical obser- 

directed by the source code or intermediate code (e.g., vation that the distribution of bytecode lengths for Java™ 

Java™ bytecode), at run time. Thus, interpretation involves bytecodes is typically one or two bytes long for each 

translating code from one language to another language bytecode. Further, the speculative compuUtion can be pcr- 

except that the translation is directly executed instead of formed efiSciently using the above described generation of 

stored for later execution. Languages (or language famihes) addresses for bytecode handlers, which reduces memory 

such as Lisp and Basic are typically interpreted straight from accesses during bytecode interpretation. Accordingly, this 

source code to native machine code. In contrast, in standard embodiment improves jump-through-register handling for a 

Java™ implementations, the interpreter interprets from the Java™ interpreter. 

Java™ class files In particular Java™ Virtual Machine ^^^^^ advantages of the present invention will 

mstrucuons (e.g Java™ bytecodes), which were compiled become apparent from the following detailed description 

from source code, arc mterpretcd by a Java™ interpreter, accompanying drawings. 
Thus, the compiled source code is converted on the fly into 

native machine code, which is then executed rather than BRIEF DESCRIPTION OF THE DRAWINGS 
stored 

FIG. 1 is a functional diagram of a Java™ computing 

Interpretmg Java™ Vnrtual Machme instructions is com- environment in accordance with one embodiment of the 

mon on existing implementations of the Java™ Virtual present invention 

Machme but is not required by either the Java™ Laiiguage piG. 2 is a block diagmm of a Java™ bytecode in 

SpecificatioD or the Java™ Virtual Machine SpedficatioD. A _ j -^u u j- * c*u /- 

i Ti«^r*,i»*i.- I 1 T. accordance with one embodiment of the present invention. 

Java™ Virtual Machine implementation can also use Just- ^ . , ^ , 

ID-Time (JIT) compilation: translating Java™ source code I Provides a bytecode compiler written m 

into native machine code at run time on the local platforai pseudocode. 

and then executing the translated (stored) native machine 4 provides a bytecode interpreter for a virtual 

code. Further, another approach is to have hardware such as machine written in pseudocode. 

a microprocessor that direaly implements the Java™ Virtual FIG. 5 provides a Java™ interpreter written in standard 

Machine instruction set so that the microprocessor executes "C" code. 

Java™ bytecodes direcUy. FIG. 6 is a block diagram of a table of cells for bytecode 

handlers stored in a memory of a computer in accordance 

SUMMARY OF THE INVENTION with one embodiment of the present invention. 

The present invention provides an interpreter with PIG. 7 provides pseudocode for generating a bytecode 
reduced memory access and improved jump-through- 50 ^^^I^'" address in accordance with one embodiment of the 

register handling. For example, the present invention pro- present invention. 

vides a cost-effective and high performance apparatus and FIG. 8 provides an example JAVA™ bytecode stream, 

method for an interpreter sudi as a Java™ interpreter that FIG. 9 is a functional diagram of a bytecode stream in 

provides reduced memory access and improved jump- accordance with one embodiment of the present invention, 
through-register handling. ss FIG. 10 is a block diagram of a memory such as a 

In one embodiment, a method includes storing handlers in computer memory storing the bytecode stream of FIG. 9 in 

cells of a predetermined size in a table, and generating an accordance with one embodiment of the present invention. 
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FIG. 11 provides pseudocode for an interpreter with Windows™ 108 is provided for a PC (Personal Computer) 

improved jump-through-register handling in accordance (e.g., a Hewlett Packard Vectra™) running Microsoft Win- 

wiih one embodiment of the present invention, dows™ 114, A Java''** VM for Unix 110 is provided for a 

FIG, 12 is a functional diagram that provides a graphical workstation (e.g., an HP 9000™ workstaUon) running 

depiction of the state of the local variables and the operand s Umx™ (e g HP-UX™) 116. Accordingly, each VM 106. 

stack while executing a bytecode stream. ^^^^"^^ native class l&rary need be wntten only 

—„ ... ~,' 1- t . once tor each platform 112, 114, and 116. In particular, a 

HG, 13 IS a state dia^am of a multi-state mterpreter m j^^^tm interpreter in the run-time system interprets the 

accordance with one embodiment of the present mvenUon. j^^^tm bytecodes of Java™ program bytecode 104 and 

FIGS. 14A-14C provide pseudocode for bytecode ban- executes instructions native to the platform, 

dlers for each state of a multi-stale interpreter for an "iadd" Because Java™ bytecodes are not specific to any particu- 

Java™ bytecode in accordance with one embodiment of the lar processor or operating system, Java™ program bytecode 

present invention. 104 is advantageously fully portable. Thus, machines as 

FIG. 15 provides pseudocode for address generation of a diverse as a machine running Apple MAC OS™, a machine 

handler for a multi-state interpreter in accordance with one running Microsoft Windows 95™, and a machine nmning 

embodiment of the present invention. HP-UX™ can use exactly the same Java™ bytecodes, and 

thus, they can execute software that originates from the same 

DETAILED DESCRIPTION OF THE source code 102. However, a typical run-lime interpretaUon 

INVE^mON of Java™ bytecodes adds significant overhead from a per- 

The present invention provides an interpreter with ^""^^f^ standpoint, 

reduced memory access and improved jump-through- ^ Java™ run-time systems arc commercially available for 

register handling. For example, the present invention is most popuUr microprocessors. Any Java™ 

- I, J * r * .u* code 1U2 can be compiled/mterpreted and run unaltered on 

parucularly advantageous for an mterpreter that requires a ^ ^ 

high performanceasweUasacost-effective implementation. j^^^,^ ^^^^^ ^^^^^^ iinplementations 112, 114, 
Generally, virtual machines advantageously provide port- ^5 and 116 and the Java™ program source code 102 satisfy the 
ability -of computer software (e.g., computer programs) appropriate standard Java™ language specification and 
across multiple platforms (e.g., microprocessor instruction Java™ Virtual Machine specification, respectively), 
sets and operating systems). For example, Java™ promises The Java™ technology also provides platform indepen- 
portability across platforms by extending the concept of dence in an intemet environment. For example, a Java™ 
encapsulation to the concept of the platform. In particular, 30 applet (e.g., a Java™ program bytecode 104) stored on a 
the Java™ technology encapsulates computer and its oper- World Wide Web (WWW) server can be downloaded to a 
ating system inside an abstract Java™ Virtual Machine user's machine. In particular, a WWW browser (e.g., 
(VM). A description of the Java™ language specification, Netscape Navigator™) executing on the user's machine 
version 1.0 and 1.1, is provided by Sun Microsystems, Inc., (e.g., a workstation, a PC, a network computer (NQ, an 
in a book entitled The Java Language Specification written 35 Apple Macintosh™, a WWW browser console, a cellular 
by James Gosling, Bill Joy, and Guy Steele and published by phone, a laptop computer, or a handheld computer) down- 
Addison-Wesley. Also, a description of the Java™ Virtual bads the Java™ applet. A Java™ interpreter executing on 
Machine, version 1.0 and 1.1, is provided by Sua the user's machine interprets and executes the downloaded 
Microsystems, Inc., in a book entitled Java WrTMa/MtzcAifie Java™ applet. For example, various versions of WWW 
Specification written by Tim Undholm and Frank Yellin and 40 browsers such as Netscape Navigator™ and Microsoft Intcr- 
published by Addison-Wesley. . net Explorer™ have included a Java™ interpreter. Also, a 
The Java™ Virtual Machine enables programmers to Java™ VM is currently provided in a commercially avail- 
obtain system-level services like process management and able Java™ Development Kit (JDK) 1.1 from Sun 
graphics, but the Java™ Virtual Machine avoids dependency Microsystems, Inc. 

on any particular operating system by using generic Java™ 45 Thus, the Java™ technology provides a programming 
class libraries designed for such tasks. Accordingly, this language that can be compiled and then interpreted to 
enables programmers to avoid dependence on a particular provide platform independence, which advantageously 
processor or operating system by using Java™ bytecodes, an allows for portability of Java™ program source code 102. In 
intermediate language as defined in the Java™ VM sped- contrast, many modem languages are fully compiled. For 
fication that can be interpreted by a Java™ interpreter. 50 example, a C++ compiler translates or compiles a C++ 
FIG. 1 is a functional diagram of a Java™ computing program source code, which represents instructions a com- 
environment in accordance with one embodiment of the puter programmer writes in C++, into native instructions for 
present invention. In particular, an original Java™ program a particular platform (e.g., the native code of a particular 
source code 102 is prepared by a computer programmer. microprocessor and calls to the native libraries of a particu- 
Instead of generating machine-specific or operating-system- 55 lar OS). The particular platform can then execute the fully- 
specific instructions (e.g., native instructions for a particular compiled program without requiring further translation. On 
machine or library calls for a particular OS), a Java™ the other hand, untike the Java™ technology, the fully- 
compilcr compiles Java™ program source code 102 into a compiled program that is now in executable form for the 
Java™ program bytecode 104. However, a general micro- particular platform, only runs on that particular platform, 
processor such as the well-known Intel X86/Pcntium™ 60 Hence, software developers must rewrite call to the native 
(e.g., in a PC 114) cannot execute Java™ program bytecode libraries for a different OS and use a different compiler to 
104 directly (i.e., without interpretation or further provide a different fuUy-compilcd program for a different 
compilation). Thus, a run time implementation of a Java™ target platform. Accordingly, C++ source code may be 
VM for a particular processor and a particular operating portable (assuming compilers exist for programming lan- 
system (OS) is provided. For example, a Java™ VM for 65 guage of the source code for the different platforms such as 
Macintosh™ 106 is provided for an Apple Macintosh™ platforms 112, 114, and 116), but executable code generally 
computer running a MAC OS™ 112, A Java™ VM for is not portable. 
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Thus, a Java*™ compiler generally does not largei a that can realistically be expected from a Java™ chip, 
particular platform, because the target is not a real machine, Further, to achieve a significantly greater gains, a Java™ 
but rather the Java™ Virtual Machine. Thus, the Java™ chip will most likely be difficult and expensive to develop, 
compiler translates Java™ program source code 102 into Moreover, general-purpose microprocessors may be pre- 
Java™ program bytecode 104, which represents a set of s fcrrcd over a Java™ -specific microprocessor. For example, 
compact byteoodc instructions. Each time the Java™ pro- general-purpose microprocessors provide significant flex- 
gram is executed or run, a Java™ interpreter interprets each ^^^^^y ^ ^^y run software written in ahnost every popular 
instruction of Java™ program bytecode 104 and executes language In contr^, a Java™ chip will likely only run 
instructionsnativetotheparticularplatformll2,114orll6. ''f^™ bytecode efficiently, practically Imiitmg a users 

_ - ^ 1 in choices to programs wntten id Java™. Moreover, non- 

Generally, a Java™ Mrtual Machme implementation 10 j^va™ chip-based platforms would still require interpreU- 

mcludes an execunon engine. In the stoidaid Java™ Virtual j^^^™ bytecodes. Accordingly, in one 

Machine specification, the behavior or the execution engme tu * • *• • ^ ' ^ a 

J, \ , J- r. . embodiment, the present mvention provides an improved 

IS denned m terms of the bytecode instruction set. For each t.„«tm <• -*u „ u i 

-„ , ^< , . Java™ mterpreter as further discussed below, 

mstruction, the Java™ Virtual Machine speciiicatioo i liij- r ttm. ji 

describes in detail the effects and side^flFects a Java™ « 2 is a blode diagram of a Java™ bytecode In 

*, 1 L- • 1 * 4- u ij « u *j * particular.abytecodestreamisasequenceof instructions for 

Virtual Machine implementation should create, but does not !lt -ruTr^^T^.. ^ -.i i 

define at the implementation level, how such an instruction {^Z^ Ff^"^ ^Jf^^" '^"^''^^ » «""=-''y"= 

fjA j-1 4- • u two-byte opcode followed by zero or more operands that 

should be executed. Accordingly, an execution engme can be l.^^ j.j. f 

implemented to execute byte«des in various mlmiers and f^'l?'^^ «f ^ ° ^V^^' °P«=°?^ "'^^''^f. "J*;^!"]" 
still be consistent with the Java™ Virtual Machine specifi- ^ ^ perfonned Operands supply mformaUon needed to 

cation. For example, the implementations can interpret, Perform the operaUons speafied by the opcode. It^ 

just-in-time (JID compile. cx<!cute natively in silicon (e.g. "^^^'^ '1*''?" " If ff ''^ 

a Java™-chip). or use a combination of these approachel T^Jf "^H^ J 

. , , , which are Java™ VM instructions, icqmre no operands and 

In particular, each thread ofarunningor executing Java™ therefore inchide only an opcode, which requires just one 
application or program is a distinct mstance of the Java™ " byte. Depending on the opcode, the Java™ VM may refer to 

Virtual Machme's execution engine. From the beginning of 5^^^^ in other areas such as a Java™ stack, which is 

the execution of the Java™ application or program to the f^^^^ discussed below, in addition to or instead of operands 

end, a thread is either executing bjlecodes or native methods ,jj j( (rail the opcode 

(i.e methods implemented in a language other than Java j„ ^i^ular, the l-byte opcode of FIG. 2 represents a 

such that It does not need o be interpreted). A thread may ^^^er that the Java™ virtual machine interprets as a 

execute bytecodes directly, by mterpretmg, executing ^^^^ instruction. For example, Java™ opcode value 104 

nauvely in silicon (e.g., a Java™ chip), or mdirecUy, or by (0x68 in hexadecimal represenUtion) repre^nts the instrac- 

jrr compUing and executmg the resulting native code. Thus, ^ ^^^. ^ ^„ ^ ^^^^ j^^^^ 

re ^enfexe^t?on°e°n es n^cUo""^ apphcation, ^^^j^^ ^^ ^ j^^^™ 

represen execu on engmes in ac ion. operand stack, multiply them, and push the product back 

A Java™ interpreter generally is not platform indepen- onto the stack. In addition to its numerical value, each 

dent. But for a given platform, creating a Java™ VM opcode has a conventional short name, caUed its mnemonic, 

implementation that wiU interpret and execute a Java™ por example, the mnemonic for opcode 104 is "imul^. A 

program bytecode 104 is generally preferable to Java™ VM also uses the opcode to determine just how many 

re-implementing every apphcation (e.g., writing a new pro- following bytes are operands for that opcode. In some cases, 

gram source code for each target platform). Accordingly, this such as the "imul" instruction, the imul's opcode which is 

flexibility makes cross-platform development much easier just one byte represents the entire instruction as no operands 

and less expensive, but at a possibly significant cost, because are needed. In other cases, an opcode may require one or 

bytecode interpretation typically causes Java™ programs to more operands. For example, the FLOAD instruction 

execute on a platform much slower than a fiiUy-compiled (opcode value 23 or 0X17 in hexadecimal) loads an FLOAD 

program executing on the platform such as a fully-compiled value from a local variable, and it uses an index operand to 

C++ computer program executing on platform 114. specify which local variable to load from. If the local 

Moreover, this performance degradation is typically a prob- variable of interest is at index 5, then the instruction would 

lem for any interpreted program. acquire two bytes written out as "23 5" (FLOAD from local 

One approach to improving interpreter performance such variable at index 5). 

as for a Java™ interpreter is to provide a Java™ -specific In one embodiment, the Java™ VM execution engine runs 

microprocessor. For example, a Java™-specific micropro- by executing bytecodes one instruction at a time. This 

cesser that can execute Java™ bytecode direcdy could be process takes place for each thread (execution engine 
provided. In other words, tiie Java™ bytecode essentially 55 instance) of the Java™ application running in the Java™ 

represents the native machine code (e.g., a subset of the VM. In particular, the execution engine fetches an opcode of 

native instruction set) of the Java™-spccific microprocessor. a bytecode stream of Java™ program bytecode 104, and if 

As a result, the Java™-specific microprocessor may signifi- the opcode has operands, then the execution engine fetches 

cantly eliminate the overhead of the second translation step, the operands. The execution engine performs the action 

the interpretation of Java™ bytecodes. Thus, a Java™ chip requested by the opcode using its operands, if any, and then 

or Java™ -specific microprocessor essentially dispenses with fetches a next opcode of the bytecode stream. Execution of 

the Java™ Virtual Machine, implemented as eiUier the bytecodes continues until a thread completes either by 

Java™ JIT compiler or the Java™ interpreter, and could remming from its starting method or by not catching a 

conceivably increase execution speeds of Java™ program thrown exception. 

bytecode. 65 [u embodiment, a critical responsibihty of an inter- 
However, limitations inherent in current microprocessor prcier (e.g., a Java™ interpreter) is determining a next 
technobgy may constrain significant performance increases instruction to execute. For example, a Java™ interpreter can 
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generally deiennine a next bylecode to fetch in one of three interpreter is by using the "switch" statement in the standard 

ways. For many instructions, the next bytecode to execute "C* programming language. 

direcdy foUows the current bytecode in the bytecode stream. However, the Java™ interpreter written in C code as 

For some instructions, such as goto or return, the interpreter shown in FIG. 5 is inefficient when the C code is compiled 
determines the next bytecode as part of its execution of a 5 and then executed on most modem microprocessors such as 

current instruction If an instruction throws an exception, the ^^^^ Pentium™ microprocessor. In particular, in the 

interpreter determines the next opcode to fetch by searching "switch" statement written in C code as in the Java™ 

for an appropriate catch clause. interpreter of FIG. 5, a lookup (able that stores a pointer to 

TUiUiTM.ui • ir*. a handler for each opcode. Ibus, the Java™ interpreter of 

Thus, the Java™ technology is an example of an mtcr- * t . i • -t. 5 r 
, , , , ^T7-*u • * * J . in FIG. 5 performs a memory access to look up the address of 

preted computer language. With interpreted computer ^ , , , , ^ . .i / 

f 1- • *L • . the table, loads an address from the table (another memory 

languages, apphcations or programs wntten in the mter- v ... - j t. ^ »_ 

J 1 * • 11 • I * J » access) corresponding to the required handler and then 

preted language typically mvolve two steps m order to . ^ i j j ? i ^ 

. TiT jumps to the loaded address. Thus, two memory accesses are 

execute the program. _/ . . . * , * i. ji r 

^ performed m order to locate the handler for executing an 

In the first step, the program text is parsed, some analysis interpreted bytecode. This extra memory access is prohibi- 

is performed, and the virtual machine instmctions that are 3 perfomiance standpoint, especially on modem 

needed to execute the program are generated. This informa- microprocessors in which a memory access is a significant 

Uon IS then output m an efficient data representation such as ^^^^^^y g-om a performance standpoint. Hence, the problem 

compact bytecode Accordingly, the compilation step is ^^ji the typical interpreter is that several memory accesses 

performed once before runnmg the program, either dynami- ^re typicaUy needed to begin execution of a handler for a 
cally as in the case of the well known SmallTalk™ computer ^ gj^^jj bytecode or P-code 

language, or as a separate process using a stand-d^ Accordingly, in one embodiment, a Java™ interpreter 
compilerasm the typicalcase of Java™. Often, byte-based ^^^^ improved performance is provided, and several 
representations are used and hence the name bytecode is memory accesses are typically needed to begin execution of 
used to refer to the compiled instmctions for the virtiial ^ ^^^^^ ^ ^^^^ ^ ^^^^^^ p^^^ g ^ ^^^^^ 
madnne. For example, FIG, 3 provides a bytecode compiler ^ ^ ^^,0 of cells 602, 604, 606, and 608 for 
written m pseudocode. However other representaUons can ^^^^^^^ ^^^^^ ^^^^^ ^ ^ ^ ^ ^ 
also be used, which are often caUed P-code (Program code) ^^^rdance with one embodiment of the present invention, 
represen a ons. particxilar, when interpreting Java™ bytecodes, the inter- 
In the second step, an interpreter iterates over the data prelerjumps only on one of 256 different opcodes (assuming 
(e.g., bytecode or P-code) produced by the first step, execut- ^n implementation compliant with the standard Java™ VM 
ing the compiled virtual machine instmctions. For example, specification, which defines 256 different bytecodes). Thus, 
FIG. 4 provides a bylecode interpreter for a virmal machine 256 different bytecode handlers, which are executable code 
written in pseudocode. In particular, the bytecode interpreter segments for a particular platform such as platform 112, 114, 
of HG. 4 steps through each bytecode in a bytecode stream, 3^ or 116, are stored in a memory of a computer. When 
determines which instmction (e.g., opcode) the bytecode interpreting a Java™ bytecode stream, the interpreter jumps 
represents, processes (when required) additional data from to the storage location of the cxecuUble code segment for 
the bytecode (e.g., operands, or other data), and then carries the bytecode handler of a particular bytecode, 
out the action required by the instruction. Each time an £n particular, these executable code segmenU for the 
instruction is executed a PC (Program Counter, which is an handlers of Java™ bytecodes are typically relatively small, 
mdex keeping track of where the interpreter is withm the j^^^ ^ p,g. a memory of a computer can be 
bytecode stream) is updated to point to a next instrucUon. allocated such that table 600 is provided widi cells 602, 604. 
The interpreter of HG. 4 is similar to Sun Microsystem's 506, and 608, which are each a power of two size, such as 
imtial Java™ mterpreter. 64 byte segments. Each bytecode handler for the 256 dif- 
Computer programming languages based on bytecode or 45 ferent byUcodes is stored in a different 64-byte cell of table 
P<ode interpreters (also called semi-compiled languages, 600. Thus, the bytecode handleis for each bytecode are laid 
because they are basically intermediate in form between out in a table in which each handler occupies a fixed amount 
fully interpreted and fiiUy compiled languages) can be much of space (e.g., less than or equal to 64 bytes), and thus the 
faster than fully interpreted languages. But execution of an bytecode handlers can be stored in cells, which size is 
interpreted language program such as a Java™ program 50 allocated to be a power of two (base two). Such cell size is 
bytecode 104 is typically in the range of 10 to 20 times convenient, because memory addresses for these cells can be 
slower than execution of a fully-compiled "C++" program. easily calculated. In FIG. 6, bytecode handler 0 is stored in 
Accordingly, in one embodiment, an interpreter with cell 602, which is a 64-byte cclL Handler 0 may not require 
improved performance is provided as further discussed 64 bytes, and thus, the allocated 64-byte cell 602 includes a 
below. 55 portion of the cell that stores no data. However, handler 1 is 
FIG. 5 provides a Java™ interpreter written in standard stored in cell 604 and handler 1 requires the entire 64-byte 
"C code. As discussed above, the core of any Java™ VM cell 604, If a handler requires more than 64 bytes of storage 
implementation is the execution engine, that is, the inter- space, then the handler can jump to space outside the cell 
preier that executes the instructions in the bytecodes of a and then return to the cell if necessary. Alternatively, any 
method of Java™ program bytecode 104. Java™ interpret- 60 fixed value can be used to define the size of cells 602, 604, 
ers such as the Java™ interpreter shown in FIG. 5 executes 606, and 608 of table 600. 

the Java™ bytecodes instruction by instruction in a method. As a result, instead of looking up in a lookup table for the 

A few state variables are provided for storing the current handler address and then jumping to that handler address, 

program counter (PC), the top of the stack (OPTOP), the the interpreter can simply calculate the handler address, 
class of the method that is being executing, and pointers to 65 Specifically, the interpreter multiplies the bytecode value by 

storage for local variables (VARS) and the stack frame. As the cell size (e.g., 64 bytes), and then add the table base 

shown in FIG. 5, a simple way to implement a Java™ address to that computed table offset (i.e., offset into the 



03/02/2004, EAST Version: 1.4.1 



us 6,256,784 Bl 

9 10 

table). Id particular, FIG. 7 provides pseudocode for gener- long. FIG. 8 provides an example Java™ bytecode stream, 

ating a bytecode handler address in accordance with one In particular, the left-hand cohimn of FIG. 8 shows the offeet 

embodimeat of the present invention. In FIG. 7, because the in bytes from the beginning of the method's bytecodes to the 

cell size is a power of 2 (in this case 64), the offset of the start of each instruction. The center column of FIG. 8 shows 

required handler from the beginning of the table is easily 5 the instruction and any operands. The right-hand column of 

calculated by a simple left-shift operation. The bytecode FIG. 8 includes comments that arc preceded with a double 

handler address is then computed by simply adding the offset slash just as in Java*™ source code, 

to a table base address, which is stored in a register of the More specifically, on entry into a particular handler for a 

microprocessor. Accordingly, the interpreter can jmnp first bytecode of a bytecode stream that includes a first 

dirccUy to Uic bytecode handler without incurring the cost of lO bytecode, a second bytecode, and a tiiird bytecode, the 

a single memory access. length of the first bytecode has been determined, as dis- 

Accordingly, this embodiment is advantageous, because it cussed above. The interpreter then speculatively computes 
reduces memory accesses performed by the interpreter when two targets for the third bytecode handler. On entry into a 
executing a bytecode stream, and in particular, it reduces particular handler for the second bytecode, the length of the 
memory access when generating an address for a bytecode 15 second bytecode has also been determined, and the inter- 
handler, preter can select one of the two precomputed targets and 

Moreover, tiiis embodiment of tiic present invention is then notify the branch unit via a hint about the destination of 
particularly advantageous for interpreting Java™ bytecode next target when the second bytecode handler completes 
that includes, for example, "for" loops. Typically, in inter- execution. Accordingly, the interpreter can provide a hint 
preting a "for*' loop around a set of Java™ bytecodes, an ^ to tiie branch logic unit about die destination of an approach- 
interpreter first jumps to the base of the "for" statement in ' jump-through-register instruction, 
order to handle tasks such as incrementing the loop counter FIG. 9 is a functional diagram of a bytecode stream in 
and checking bounds, and then jumps back to a "switch" accordance with one embodiment of the present invention, 
statement to execute the bytecodes within the loop, as in the At byte 0 of the bytecode stream is opO, which includes no 
switch implementation of a Java™ interpreter as discussed ^ arguments (operands) so this bytecode is one byte in length, 
above with respect to FIG, 5. Opl begins at byte 1 and includes one argument, and thus. 

In one embodiment, a Java™ interpreter loads a next this bytecode is two bytes in length. Op2 begins at byte 3 and 

bytecode handler by directly computing the address of the includes no arguments, and tiius, this bytecode is only one 

bytecode handler for die next bytecode. The interpreter can hyte in length. Similarly, op3 begins at byte 4 and includes 

then jump direcUy to the bytecode handler thereby elimi- no arguments, op4 begins at byte 5 and includes no 

nating one of the jumps that was typically reqmred by a arguments, and op5 begins at byte 6 and includes no 

standard Java™ interpreter, accordingly, a Java™ interpreter arguments. 

in accordance with one embodiment of the present invention FIG. 10 is a block diagram of a memory 1000 such as a 

reduces the number of branches required per bytecode to computer memory storing the bytecode stream of FIG. 9 in 

essentially one branch per bytecode rather than two branches accordance with one embodiment of the present invention, 

per bytecode. Moreover, because this path is executed for As shown in FIG. 10, instruction 0 is one byte in length, 

each Java™ bytecode within a "for" loop, this embodiment Instruction 1 is two bytes and sequentially follows instruc- 

provides a Java™ interpreter with significantly improved tion 0 in memory 1000. Instmction 2, instruction 3, and 

performance. ^ instruction 4 are each one byte in length and stored sequen- 

In one embodiment, an interpreter with reduced memory tially in memory 1000. Finaily, instruction 5 is two bytes in 

access is hand-coded in assembly language. In particular, the length and follows instruction 4 in memory 1000. Thus, 

hand-coded-assembly-language-implemented interpreter when the interpreter is executing a handler for opO of FIG. 

can generally execute significanUy faster than a typical 9, the interpreter knows that opO requires one byte. The 

interpreter. . interpreter can then precompute the handler address for op2 

Another problem with a standard interpreter such as a speculatively computing a first target address, which 

typical Java™ interpreter is that execution of a bytecode assumes that opl is one byte in length, and a second target 

handler typically requires a jump-through-register address, which assumes that opl is two bytes in length, 

operation, which is inefiBcient on most modem RISC In other words, the interpreter is speculating that instruc- 

(Reduced Instruction Set Computing) microprocessors. 50 tion 2 is stored either two bytes ahead or three bytes ahead 

Accordingly, in one embodiment of the present invention, an of the current PC (Program Coimter). In one embodiment, 

interpreter that inchides improved jump-lhrough-register each thread of an executing program maintains its own PC 

handling is provided. In particular, an interpreter eflBcientiy register, or Program Counter, which is created when the 

handles a jump-through -register operation by ^jeculatively thread is started. The PC register is one word in size, so it 

computing a first target address of a second handler and a 55 can bold both a native pointer and a return value. For 

second target address of the second handler, and then example, as a thread executes a Java™ method, the PC 

selecting one of the precomputed target addresses in order to register contains the address of the current instruction being 

provide a hint to a branch unit of the nucroprocessor about executed by the thread. An address can be a native pointer 

the destination of an approaching jump-through-registcr. or an offset from the bcgirming of a method's bytecodes or 

Specifically, in one embodiment, the interpreter begins 60 P-codes. If a thread is executing a native method, then the 

computing target handler addresses several bytes ahead in value of the PC register is undefined, 

the instruction stream (e.g., bytecode stream). The specula- FIG. 11 provides pseudocode for an interpreter with 

tive computation of the target handler addresses is based on improved jump-through-register handling in accordance 

the empirical observation that the distribution of bytecode with one embodiment of the present invention. In particular, 

lengths is usually significantly xmeven. For example, in 65 FIG. 11 provides an opO handler, an opl handler, and an op2 

Java™ bytecode streams, the vast majority of bytecodes handler written in pseudocode in accordance wiUi one 

(both statically and dynamically) are either one or two bytes embodiment of the present invention. In the opO handler, the 
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interpreter begins computing the handler address for the op2 accordance with this embodiment can further improve per- 

handler while executing the opO handler As discussed formance of the interpreter by providing improved juinp- 

abovc, because the interpreter speculates that opl is either through-register handling thereby avoiding a significant 

one or two bytes in length, the opO handler computes the pipeline bubble penalty that would likely be suffered if the 

handler address for the op2 handler by calculating the s next handler address was not prefetched. Thus, this embodi- 

handler address for byte 2 and calculating the handler m^nt allows for a time shift in calculation of addresses well 

address for byte 3 Ilie opO handler then performs work fo^ in advance of the actual jumps to the handlers, which 

opO. lUe opO^handler then performs a jump-through-register advantaecously reduces the amoimt of time, and thus the 

operation to jump to the next handler address, which takes ^^^^^ j ^ ^^^^ ^ jump-through- 

the interpreter to the opl handler. • * 

, ^ , „ , . .10 register operation. 

Upon entry into the opl handler, the mlerpreter acquires . u * . /i \ i 

the length of opl. lHus, the opl handler can appropriately In one embodiment, wriUng to Ooading) a parUcular 

select L prefetched (precomputed) next handler addre^ I'^'^j the microprocessor tnps or triggers the prefetch 

(next_handler„addr). In this case, because opl is two bytes ^^^^^ ''^i' T "^^^ f ? ^^P^^^,,*^^^"':^ 

in length, the interpreter selects the handler address for byte ff^ l"" '""^u ^1 ^'f ^ ' 

3. TTie opl handler then computes the next handler address l'^'^ ^^"^'^ written m the register. For 

for the op3 handler. In particular, the interpreter calculates "^^P^"* " ^^P^^ ^^^ister. 

the handler address for byte 4 and calculates the handler 1° embodiment, an interpreter that provides 

address for byte 5, whicb is speculating that the op3 is either improved-jump-through-register handling is hand-coded in 

one or two bytes in length, respectively. The opl handler ^ assembly language. In particular, the hand-codcd-assembly- 

then performs the work for opl. The opl handler then language-implemented interpreter can execute significandy 

performs a jump-through-register operation to jump to the ^^^ter than a typical interpreter. 

next handler address, which lakes the interpreter to the op2 Another important feature of a programming language 

handler. such as the Java™ programming language is that it is a 

Upon entry into the op2 handler, the interpreter knows the 25 stack-based computer programming language. In particular, 

length of ap2 and thus selects the next handler address ^^^^ ^ ^^^^^ ^f a Java'^w program is launched, the 

appropriately. In this case, the op2 handler selects the Java™ VM creates a new Java™ stack for the thread. A 

handler address for byte 4, because the interpreter knows Java™ stack stores a thread state in discrete frames. The 

that op2 is one byte in length. The op2 handler performs a Java™ VM performs two operations direcUy on Java™ 

prefetch operation for prefetching an op4 handler address. In 30 stacks: it pushes frames onto the stack, and it pops frames 

particular, the op2 handler calculates the handler address for stack. The method that is currently being executed 

byte 5 and calculates the handler address for byte 6, which by a thread is the thread's current method. The stack frame 

is assuming that op3 is either one or two bytes in length, for the current method is the current frame. The class in 

respectively. The op2 handler then performs the work for which the current method is defined is called the current 

op2 appropriately. Finally, the op2 handler performs the 35 current classes constant pool is the current 

jump-through-register operation to the next handler address, constant pool. As it executes a method, the Java™ VM keeps 

which lakes the interpreter to the op3 handler. track of the current class and current constant pool. When 

Moreover, in one embodiment, an interpreter performs the ^« ^ encounters instructions that operate on data 

above described prefetch of handler addresses without pre- ^^^^^^ ^ ^® ^^^^ performs those operations m the 

computing the handler address for the same byte more than 40 ^ ^^^^^ invokes a Java™ method, the 

once . For example, an interpreter can be provided that would J*^*™ ^ ^^^^^^^ and pushes a new frame onto the thread's 

not calculate the handler address for byte 5 more than once, J^^^™ stack. The new frame then becomes the current 

which in the interpreter implementation shown in HG. U ^ **** executes, it uses the frame to store 

was calculated more than once, and specifically, the opl parameters, local variables, intermediate computations, and 

handler and the op2 handler both calculated the handler 45 

address for byte 5. In particular, this can be implemented by A Java™ method can complete itself in either of two 

only calculating the handler address for two bytes ahead if ways. If a method completes by executing a return 

the next handler address is selected to have only been one instruction, the method has a normal completion. If the 

byte ahead. For example, referring to FIG. 11, in the method completes by "throwing" an exception, the method 

execution of the op2 handler, the next handler address is 50 bas an abrupt completion. When a method completes, 

selected for byte 4, which represented a one byte ahead whether normally or abrupdy, the Java™ VM pops and 

prefetch during the executing of the opl handler. Thus, the discards the method's slack frame. The frame for the pre- 

op2 handler would only calculate the handler address for ^ious method then becomes the current frame, 

byte 6, which represents a two byte ahead prefetch, thereby The data on a thread's Java™ stack is generally private to 

avoiding calculating the handler address of byte 5 more than 55 that particular thread, and there is not an easy way or 

once (the handler address of byte 5 was calculated as a two advisable for a thread to access or alter the Java™ stack of 

byte ahead prefetch during the execution of the opl handler). another thread. When a thread invokes a method, the meth- 

Accordingly, the present invention provides an interpreter o<i's local variables are stored in a frame of the invoking 

that precomputes target handler addresses in advance of an thread's Java™ stack. Thus, the thread that invoked the 

approaching jump-through-rcgister operation. Moreover, in 60 rnethod can access the local variables, 

one embodiment, the precomputation of the handler However, the Java™ stadc need not be stored contigu- 

addresses is inexpensive from a performance standpoint, ously in memory. For example, frames can be allocated from 

because the handler addresses can be implemented as a shift a contiguous stack, or each frame can be allocated separately 

operation and an add operation using only one memory from a heap, or some combination of both. The actual data 

access, as described above. For example, if an interpreter 65 structures used to represent the Java™ stack depend on the 

executing on a microprocessor efficiently performs the particular implementation of a Java™ interpreter. For 

prefetch operation described above, then the interpreter in example, various implementations of the Java™ interpreter 
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can allow users or programs to ^lecify an initial size for 
Java'^ stacks, as well as a maximum or minimum size. 

Similar to the local variables, the operand stack is orga- 
nized as an array of words. But unlike the local variables, 
which are accessed via array indices, the operand stack is S 
accessed by pushing and popping values. If an instruction 
pushes a value onto the operand stack, a later instruction can 
pop and use that value. 

The Java**^ VM stores the same data types in the operand 
stack that it stores in the local variables: int, long, float, 
double, reference, and remraType. The Java™ VM converts 
values of type byte, short, and char to int before pushing 
them onto the operand stack. 

Other than the program couLnter, which generally cannot 
be directly accessed by Java™ instructions, the Java™ VM 
specification requires no registers (e.g., for implementing 
the Java™ stack). Thus, the Java™ VM is stack-based rather 
than register-based, because its instructions lake their oper- 
ands from the operand stack rather than from registers. 
Instructions can also take operands from other places, such 
as from parameters immediately following the opcode in the 
bytecode stream, as discussed above, or from the constant 
pool. 

The Java™ VM uses the operand stack as a work space. ^ 
Many Java™ instructions pop values from the operand 
stack, operate on them, and push the result back onto the 
stack. For example, an "iadd" instruction adds two integers 
by popping two ints off the top of the operand stack, adding 
them, and pushing the int result back onto the stack. For 
example, the Java™ VM can be implemented to add two 
local variables that contain ints and store the int result in a 
third local variable as follows: 



iload_0 


//push tte iiU in local variable 0 


aoad_l 


//push the iat in local variable 1 


iadd 


//pop two ints, add them, push 




//result 


istore_2 


//pop int, store into local 




//variable 2 



15 



20 



35 



-10 



In the above sequence of Java™ bytecodes, the first two 
instructions, "iload_0*' and "iload_r', push the ints stored 
in local variable position 0 and 1 onto the operand stack. The 45 
"iadd" instruction pops these two int values, adds them, and 
pushes the int result back onto the operand stack. The fourth 
instruction, "istore_2", pops the result of the iadd off the top 
of the operand stack and stores it into local variable 2. FIG. 
12 is a functional diagram that provides a graphical depic- 50 
tion of the state of the local variables and the operand stack 
while executing the above bytecode stream. In FIG. 12, 
unused slots of the local variables and the operand stack are 
shown as blanks (blank slots). 

According to the standard Java™ VM specification, 55 
implementation designers can represent the Java™ stack in 
whatever way they wish. Various Java™ interpreters use a 
variety of ways of implementing the Java™ stack in a 
computer memory (e.g., disk storage or cache memory), 
such as allocating each frame separately from a heap, 60 
allocating frames from a contiguous stack, or some combi- 
nation of both. 

However, accessing memory such as disk storage or even 
cache memory in order to push or pop from the Java™ stack 
significantly reduces the performance of a Java™ inter- 65 
preter. One approach to deal with this problem is to provide 
a Java™ chip as discussed above, which provides special- 



dedicated stack registers that keep a certain depth of the 
Java™ stack in registers on the microprocessor rather than 
in memory that is off-chip such as disk storage or on-chip 
such as cache memory. But this approach requires providing 
and dedicating special registers for the Java™ stack. 
Moreover, providing a microprocessor that is ^ecdfically 
implemented to interpret or execute Java™ bytecodes 
quickly, is expensive and may be disadvantageous, because 
the Java™-specific microprocessor may not execute non- 
Java™ applications as efficiently as a general 
microprocessor, as discussed above. 

Accordingly, FIG, 13 is a state diagram of a multi-state 
interpreter in accordance with one embodiment of the 
present invention. In particular, multiple versions of a 
Java™ interpreter are provided, in which each version is 
specific to a particular state. Astate is defined by the number 
of registers that are storing elements from the top of the 
stack, that is, the number of elements stored in a Java™ 
slack that are currently written (loaded or stored) in registers 
on the microprocessor. 

In one embodiment, four states are provided, because it 
has been empirically observed that if the top two or three 
elements of the Java™ stack are kept in registers of the 
microprocessor, then the number of memory accesses 
needed for stack operations is significantly reduced. In 
particular, four versions of the Java™ interpreter are 
provided, one version for each of the following cases; 0, 1. 
2, or 3 stack elements stored in registers of the micropro- 
cessor. Thxis, if each version of the mxilti-state interpreter is 
viewed as being a state in a finite-state automaton, then each 
different bytecode causes a deterministic transition to a new 
state. In FIG. 13, a "0" state refers to the state in which zero 
stack elements are stored in (general) registers of the 
microprocessor, a "1" state refers to the state in which one 
element of the stack (e.g., the top element of the stack) is 
stored in a register of the microprocessor, a "2" state refers 
to the state in which two elements of the stack (e.g., the top 
two elements of the stack) arc stored in registers of the 
microprocessor, and a "3" state refers to the state in which 
three elements of the stack (e.g., the top three elements of the 
stack) are stored in registers of the microprocessor. 

In particular, FIG. 13 shows the deterministic transition to 
a new state for an "iadd" operation, which uses two stack 
elements and produces one new element, which is the sum 
that is pushed onto the stack. If there arc an insufScient 
number of stack elements stored in registers to complete the 
operation, then the interpreter determines the number of 
elements needed to be moved from memory (e.g., the slack 
stored in computer memory such as disk storage or cache 
memory) to the registers. For example, the iadd instruction 
is performed by popping two elements from the stack. If the 
interpreter is in state 2, then both of the two stack elements 
from the top of the stack are stored in registers of the 
microprocessor, and thus, the interpreter can use the two 
slack elements stored in registers. The interpreter then stores 
the result of the iadd operation, the sum, in a register (on the 
top of the stack). Thus, the interpreter is now viewed as 
having only one value on the stack stored in registers of the 
microprocessor. Thus, the interpreter transitions to state 1 as 
shown in FIG. 13. A different version of the interpreter 
would be used in state 1. The state 1 version of the 
interpreter executes bytecodes assuming that only one value 
is stored in registers of the microprocessor. If the next 
bytecode operation is a subtract operation, then the state 1 
Java™ interpreter xises one value, one argument, from the 
registers of the microprocessor, and the other value, the 
other argument, is obtained from the top of the stack stored 
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in memory, which requires a memory access (e.g., to cache 
memory or disk storage). The stale 1 Java"^ interpreter then 
pushes the result back onto the top of the stack, and in 
particular, stores it in a register of the microprocessor, and 
the interpreter remains in state 1. 5 

Accordingly, in this embodiment, the number of values 
that arc stored in registers, that is, the number of values from 
the top of the stack that are currently stored in registers of 
the microprocessor, vary dynamically depending on how the 
bytecode stream is flowing. Hence, the multi-state Java™ 
interpreter transitions between different states (e.g., states 0, 
1, 2, and 3). Further, because it has been empirically 
observed that the Java*™ interpreter executing bytecode 
streams usually only uses 0, 1, 2, or 3 elements from the top 
of the stack, the multi-state Java™ interpreter that includes ^5 
four states as described above, can operate almost exclu- 
sively out of the registers thereby providing a Java™ inter- 
preter with reduced memory access. Thus, the multi-state 
Java™ interpreter with reduced memory access significantly 
increases performance by operating in various slates that are ^ 
based on the number of stack elements stored in the registers 
of the microprocessor. 

FIGS. 14A-14C provide pseudocode for bytecode han- 
dlers for each state of a three-slate interpreter for an "iadd" 
Java™ bytecode in accordance with one embodiment of the ^ 
present invention. In particular, "iadd-0 cached" bytecode 
handler performs the iadd operation assuming that no ele- 
ments of the top of the stack are stored in the registers of the 
microprocessor, "iadd-1 cached" bytecode handler performs 
the iadd operation assuming that one element of the top of 
the stack is stored in one of the registers of the 
microprocessor, and "iadd-2 cached" bytecode handler per- 
forms the iadd operation assuming that two elements of the 
top of the stack are stored in the registers of the micropro- 
cessor. The bytecode handlers provided in FIGS. 14A-14C 
advantageously only load a stack element from memory if 
the stack element is not already stored a register of the 
microprocessor. Further, the bytecode handlers of the iadd 
operation as shown in FIGS. 14A-14C each write to a 
special register that tells the branch predictor to prepare to ^ 
branch to the loaded address, which is advantageous for 
jump-through-register handling for an approaching jump- 
through-registcr operation, as disciissed above. In one 
embodiment, a unique handler is provided for each bytecode 
and for each state of a multi-state interpreter. 

In one embodiment, an efficient transition between the 
various states of the multi-state interpreter is provided by 
storing the bases (base addresses) of the interpreter loops for 
the various stales in various registers of the microprocessor. 
For example, Kq is the base of the interpreter loop for state 
0, Rj is the base for the interpreter loop for state 1, is the 
base of the interpreter loop for state 2, and R3 is the base for 
the interpreter loop for state 3. 

FIG. 15 provides pseudocode for address generation of a 55 
handler for a multi-slate interpreter in accordance with one 
embodiment of the present invention. In particular, FIG. 15 
provides pseudocode to jump to the next bytecode handler 
from a state 1 iadd handler and a per-opcode-handler size of 
64 bytes. Accordingly, the calculation of the next bytecode 
handler during a state transition can be efficiently imple- 
mented as shown in FIG. 15, which is similarly discussed 
above with respect to FIG. 7. 

Alternatively, a different number of stales can be selected 
for a multi-state interpreter and inteipreter loops provided 65 
for the selected number of states accordingly. Further, the 
multi-state interpreter approach is advantageous for inter- 
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pre ted stack-based languages generally and is not limited to 
the Java™ programming language. 

Accordingly, the present invention provides an interpreter 
with reduced memory access and unproved jump-through- 
register handling. In one embodiment, a Java™ interpreter 
with reduced memory access and improved jump-through- 
register handling is provided. For example, an interpreter for 
an interpreted programming language that is compiled into 
bytecode streams or P-code streams that include bytecodes 
or P-codes, re^ectively, of an empirically predictable length 
would significantly benefit from the present invention. Also, 
an interpreter for an interpreted programming language that 
uses bytecode or P-code handlers that can be stored in a table 
of cells would significantly benefit from the present inven- 
tion. 

Although particular embodiments of the present invention 
have been shown and described, it will be obviotis to those 
skilled in the art that changes and modifications may be 
made without departing from the present invention in its 
broader aspects, and therefore, the pending claims are to 
encompass within their scope all such changes and modifi- 
cations that fall within the true scope of the present inven- 
tion. 

What is claimed is: 

1. A method for prefetching instructions in an interpreter 
of variable length instructions of a virtual machine, com- 
prising: 

while executing a handler for a first instruction, comput- 
ing a first target address and a second target address, 
said first target address and said second target addresses 
each corresponding to a prediction of a starting address 
of a handler of a second instruction; and 

while executing a handler for a third instruction, said third 
instruction being an instruction provided in order of 
execution between said first and said second 
instructions, selecting one of said first and second target 
addresses as a starting address of a handler of said 
second instruction. 

2. The method of claim 1 wherein said computing said 
first target address and said second target addresses com- 
prises speculatively computing the target address for the 
handler of said second instruction. 

3. The method of claim 2 wherein the handler for said first 
instruction is for a first bytecode of a bytecode stream, and 
the handler for said second instruction is for a third bytecode 
of the bytecode stream, which is separated by a second 
bytecode in the bytecode stream that is stored sequentially in 
a memory. 

4. The method of claim 3 wherein computing the first 
target address comprises generating a handler address for 
one byte ahead of an address for the second bytecode. 

5. The method of claim 4 herein computing the second 
target address comprises generating a handler address for 
two bytes ahead of the address of the second bytecode. 

6. The method of claim 5 wherein said selecting one of the 
first and second target addresses occurs during execution of 
the handler for the second bytecode depending on a length 
of the second bytecode, said method setting the next handler 
address equal to the selected target address. 

7. The method of claim 3 where said computing a first 
target address and a second target address further comprises 
calculating a handler address for one byte ahead of the 
second bytecode, and calculating a handler address for two 
bytes ahead of the second bytecode. 

8. The method of claim 7 further comprising executing a 
jump -through-register using the selected handler address. 

9. The method of claim 8 wherein the interpreter calcu- 
lates the handler address for a particular byte only once. 
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10. The method of claim 8 wbercin the bytecxde stream 
is a Java™ bytecode stream. 

U- The method of claim 8 wherein the interpreter is 
implemented in assembly language. 

12. An apparatus comprising: 

an interpreter that executes on a machine for interpreting 
virtual machine instructions; and 

a table including a plurality of fixed size cells stored in a 
memory, said cells each including a handler for an 
instruction of the virtual machine; 

wherein said interpreter generates a handler address for a 
bytecode of a bytecode stream by performing a shift 
operation and an add operation using an oSset into the 
table and a table base address and prefetches the 
handler address for an approaching jump-through- 
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register operation by ^eculatively computing a first 
target address and a second target address, the first 
target address being the handler address for one byte 
ahead of a next bytecode in the bytecode stream, and 
5 the second target address being a handler address for 
two bytes ahead of the next bytecode. 

13. The apparatus of claim 12 wherein writing to a 
predetermined register of the machine triggers a branch 
logic unit of the machine to use a prefetched next handler 
address for an approaching jump-through-registcr operation, 

14. The apparahis of claim 12 wherein the interpreter is a 
Java™ interpreter. 

15. The apparatus of claim 13 wherein the interpreter is 
implemented in assembly language. 

***** 
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